3GPP defines a logical function Diameter Routing Agent (DRA) responsible for handling the Evolved Packet Core (EPC) and IP Mulitimedia Subsystem (IMS) interfaces Gx, Gxa, Gxb, Gxc, Rx and Sd. Reference is made to FIG. 1, a logic DRA such as DRA 10 or 20 serves a diameter realm comprising a single logic Policy Charging Rules Function (PCRF) unit, such as units 31, 32 that might be deployed by means of multiple and separately addressable PCRFs (see also 3GPP TS23.203, release 11). Diameter related commands may be received from the DRA 10, 20 from the entities shown on the left-hand side of FIG. 1, e.g. a serving gateway (S-GW) 10, a Packet Data Network Gateway, P-GW 11, any other non-3GPP gateway 12, from an evolved Packet Data Gateway ePDG 13, from an Application Function (AF) 14 or a Traffic Detection Function (TDF) 15.
A DRA serving two or more addressable PCRFs should be able to correlate AF service session information received over Rx interface with the corresponding IP-CAN (Internet Protocol Connectivity Access Network) session earlier received over the Gx interface (PCC—(Policy and Charging Control) session binding).
This is shown in further detail in FIG. 2. On an initial diameter command within a new IP-CAN session (step 1) DRA 20 selects one of the available and load-shared PCRFs 31, 32 and relays the command to PCRF, e.g. PCRF 31 in the example shown (step 2). The DRA 20 should be able to remember the selection for any subsequent command belonging to the same data packet session. A packet sent from an application function 14 over the Rx interface (step 3) that belongs to the same session should be relayed to the same addressable PCRF entity, here PCRF with reference numeral 31 (step 4). The other PCRF 32 is not able to handle subsequent commands belonging to the session because it has not been involved in any packet belonging to that session.
In practice, a logical DRA function can be deployed by means of two or more addressable DRA units, e.g. for load sharing or redundancy reasons. Such a situation is shown in FIG. 3. In this case, the gateway 11 and the application function 14 are free to pick any of the DRAs, DRA 20 or DRA 21, which are comprising a common logic DRA function.
Repeating the same use case as mentioned above, the P-GW 11 might send an initial diameter command of a new IP-CAN session to DRA 20 (step 1) while subsequent commands belonging to the same session might be sent to the other DRA, DRA 21 (step 3). DRA 21 now has to be able to deduce PCRF 31 in step 4 that was chosen by DRA 20. Otherwise, if DRA 21 relates to PCRF 32, the associated call would be broken as session information is not synchronized between PCRF 31 and PCRF 32.
Consequently, DRA 20 and DRA 21 require external data synchronization of some kind to be able to share the session information across all addressable DRAs that are part of a common logical DRA function. 3GPP 23.203 defines the network function DRA but does not mention the prior mentioned scenarios of two DRAs, mated DRAs. However, it is desirable to run DRAs as mated pairs in telecommunication networks in order to cater for failure redundancy.
One possibility to overcome this problem is the use of synchronization as symbolized by the sync connection in FIG. 3 between DRA 20 and DRA 21. However, this synchronization is problematic for several reason that will be explained below. DRA 20 must make sure that DRA 21 gets hold of session information from the IP-CAN session of step 1 before DRA 21 receives subsequent commands belonging to the session in step 3. The session information replication from DRA 20 to DRA 21 can take place either just before, after or simultaneously to relaying the diameter command to PCRF 31 in step 2. Replication can either be synchronous or asynchronous. If DRA 20 replicates session information to DRA 21 synchronously either just before, after or simultaneously to relaying to PCRF in step 2, delivery to PCRF 31 is delayed. DRA 20 has to wait for the geographical separated DRA 21 to commit the session information update. The session update time can significantly suffer with immediate impact on the other network entities and the user experience. If DRA 20 replicates session information to DRA 21 asynchronously this might lead to the situation that session information arrive at DRA 21 too late, so that no matching session information is found when the message is received in step 3 of FIG. 3. The user session is broken as DRA 21 cannot deliver to the right PCRF.
This leads to a dilemma. In both options, either performance or reliability is degraded to a level disparate with telecom grade signalling requirements. Another problem can be seen in the fact that even if session information is successfully replicated to the other DRA 21, DRA 21 might undergo a recovery (node failure/restart) and as a result lose its session information. Again, the user session is broken if subsequent commands are sent to DRA 21.
A further problem can be seen in the fact that session information might be replicated to DRA 21 through it is never going to be used, e.g. if all subsequent commands go to DRA 20. This would lead to superfluous traffic load between the two DRAs 20, 21.